The present invention is in the field of wireless communication, in particular cellular communication where a wireless or wired device or Dev (e.g., appliance) can communicate wirelessly in the wireless network, particularly cellular network, wireless internet network and short range communication (SRC) network. The PCMD (Program Control & Monitor Device) or Dev (e.g., appliance:—the inventor uses the term “Dev” for the description of this invention in the rest of this text, while the term “appliance” will be used in the claims that follow at the end of this text) communicates with a handset (e.g., cellular handset) or plurality of cellular handset, and the Dev can also be directed by any one of the handsets (e.g., mobile devices), which also can be a smart phone, tablet, tablet PC, laptop PC, VoIP device, iPad-like device, PDA (Personal Digital Assistant), any portable electronic device, wearable device (i.e., smart watch, smartwatch, fitness tracker or the like) or mobile device, so that the Dev can be used to monitor and control its environment, associated equipment, or plurality of associated equipment, and alert when any unauthorized or unsafe events take place, so its owner(s) can take appropriate measure to deal with the situation.
The Dev can also allow the user to add (register) another handset, so the owner of said handset can have the same access to the vehicle/home control and monitor system, as the original user. The Dev also lets the user remove (deregister) a missing, stolen or no longer used handset.
The Dev can also allow the user hundreds or thousands of miles (kilometers) away from home, to program the handset of a friend or a relative to have access to the home security and monitor system, so said friend or relative can stay at his/her home for a programmable period of time.
The Dev can also allow the user to program the handset of the household help personnel (i.e., cleaning person) to have access only to a certain limited function of the home security and monitor system, such as: entry and exit on certain day(s) of the week and certain time. And such the entry and exit record can be created, stored and viewed by the user.
The Dev can also alert the user when someone attempts to register his/her handset into its control and monitor system so the user can be aware of such attempt and has the option to allow or not allow it to take place.
The Dev can also let the user locate the GPS location of another missing registered handset via his/her handset.
The Dev can also allow the user to have the liberty of choosing another cellular service provider by providing a fairly simple mechanism to which it can be easily activated and registered into the new network.
The Dev can also allow the user remotely to enter and retrieve data to and from the GPS, and inquire the vehicle current location through said GPS.
The Dev can also allow the driver to pay the toll collector (i.e., bridges, highways) electronically and the transaction account is stored in memory for later review.
The Dev can also allow the user to record and view remotely the driving habit of other drivers, such as: driving speed, and optionally alerts the user when such maximum speed limit happens: where, when and the duration. It also allows car rental, taxi, truck companies, and the like, to have the driving record of each vehicle transmitted and stored into the company's storage servers for later review.
The Dev can also alert the car owner when an authorized moving or entry in of his/her vehicle. It lets the owner know the location and time of where and when the event took place.
The Dev can also alert the driver who might be leaving a child or pet inside his/her parked vehicle, which is extremely dangerous, when the temperature is either very warm or very cold outside.
The Dev can also alert the driver who might accidentally leave the car engine on (idle) for a long period of time especially in a closed environment (garage) where the potential of carbon dioxide poisoning is at the greatest. If no response from the driver/owner, the Dev will automatically turn off the engine and all its accessories (i.e., radio, lights, A/C, etc.).
The Dev can also allow the user to program, control, and monitor his/her vehicle and its accessories remotely through his/her handset.
The Dev can also alert the emergency center in case of an accident such as: a sudden impact happens to the vehicle and/or its airbag is inflated. It also lets the driver communicate via the hands-free speaker and microphone with the emergency operator. The driver can also talk to a family member of his/hers (another registered handset), with the aid of the vehicle “dial and talk” button, in case his/her phone does not work or is not in his/her possession.
The Dev can also allow a third party (police/firefighters/emergency personnel) to take possession over the vehicle when said vehicle has been stolen/hijacked and is being driven dangerously without regard for public safety. This can be accomplished by transmitting a third party control and monitor command (with a MSK) to said third party by its registered handset and at the same time the Dev receives a notice with a MSK verification key from said registered handset that said command has been transmitted to said third party or by the Dev itself transmitting said third-party control and monitor command to said third party.
The Dev can also allow the user to lock/unlock the car door, car trunk, start and drive his/her vehicle without using the car key. The user can use his/her registered handset to communicate with the Dev or use voice commands directly to the Dev (with the handset in his/her possession or the vicinity) in controlling his/her vehicle such as: lock/unlock the car door, car trunk, turn on/off lights, starting the vehicle engine (with or without a car key) or the likes.
The Dev can also allow a user, who loans out his/her car to a friend or relative (i.e., borrower), to program the Dev remotely via his/her handset to restrict borrower's usage of said vehicle to a time limit. The user's handset does it by having the Dev generated a unique one-time and time-limited MSK and then transmitted it to the borrower's handset. The borrower then uses his/her handset or voice commands (with the handset in his/her possession or the vicinity) to lock/unlock the car door, car trunk, start/stop engine (with or without of car key), drive the car and the likes. When the length of the borrowing period expires, the Dev invalidates its MSK and borrower cannot use said car any longer because his/her handset and the Dev can no longer have valid communication.
The Dev can also allow a driver who has time-limited use of its vehicle i.e., a car lessee who leases said vehicle from a car leasing company. The car leasing company's Application Server (app) generates a unique one-time and time-limited MSK and transmitted it to both the car lessee's handset and the Dev. The lessee uses his/her handset or voice commands (with the handset in his/her possession or the vicinity) to lock/unlock the car door, car trunk, start/stop engine (with or without of car key) and the likes. When the lease expires, the lessee returns the car back to the leasing company and the Dev invalidates its used MSK.
The Dev 106 preferably can also allow a user (driver/passenger) who has time-limited use of its driverless (self-driving) vehicle i.e., a car lessee who leases said vehicle from a car leasing company. The car leasing company's Application Server, via its Car Rental App (one of 3rd Party Apps block 613 in FIG. 6), generates a unique one-time and time-limited MSK and transmits it to the car lessee's handset (assuming said handset containing its corresponding app download). The lessee then is able to use his/her handset to lock/unlock the car door, car trunk, start/stop engine, input the destination to the GPS and the vehicle then drives itself to said destination and the likes. Or the lessee uses his/her voice commands (with the handset in his/her possession or the vicinity) to lock/unlock the car door, car trunk, start/stop engine, communicate the destination to the Dev which translates said command to the GPS and then makes the vehicle drive itself to said destination and the likes. When the lease expires, the lessee returns the car back to the leasing company; the Dev then invalidates its used MSK and transmits the lessee's usage data to the company's data server for accounting and processing.
The Dev 106 and its associated app (Ride-Sharing App, one of 3rd Party Apps block 613 in FIG. 6) preferably can also offer the user (passenger) requesting an online ride-sharing service with the added confidence of boarding the correct vehicle and the (ride-sharing) driver connecting with the correct passenger. Both the user's handset and the Dev (or the driver's handset) will signal (because their SRC communication, assigned with the same unique MSK, has been verified as valid) to their corresponding owners with a positive confirmation (for example, by emitting sound from their corresponding handsets and/or blinking the vehicle lights).
The Dev can also alert the vehicle owner if someone or something attempts to plant an adverse object: alien or harmful device such as GPS tracker, explosive device, illegal substance or the likes, by detecting its presence via its external smart motion, video, audio, frequency sensors; and/or especially, in the case of a GPS tracker, via its Frequency Hopper (i.e., TMSI, IMSI detector). It records the video of the said person or said something moving toward its vehicle or within its vehicle peripheral leading to a physical contact. The Dev can also, via its cameras, employ facial recognition technology, as are well known to those of ordinary skill in the art, to record images of persons of interest who, more than one occasion (or determined number of times), snoop around in its vicinity. It then transmits said recorded video to the owner's handset for his/her visual verification and determination.
The Dev can also allow the user to use its control and monitor system to program, control and monitor his/her home security system, such as: turning on or off the alarm, monitoring and viewing the house entries and exits, viewing its motion sensing devices, and observing its interior and exterior surroundings remotely, through his/her handset.
The Dev can also alert the home owner when an authorized or illegal entry takes place in his/her own house or business premises. It lets the owner know the exact location within the house or business premises, and time when it happened.
The Dev can also alert the home owner when the monitor camera detects changes in its inputs, then transmits the video images to the owner for his/her viewing and decision.
The Dev can also communicate wired/wirelessly with one or plurality of wireless handsets/terminals, computers, servers, and the like so account information can be exchanged between the Dev and one or plurality of device, such as: handsets/terminals, servers/computers (wire/wireless) to facilitate the financial (or non-finance) transaction or any other needed financial (or non-finance) exchanges.
The Dev can also communicate wired/wirelessly with one or plurality of household appliance/equipment at home or on business premises, with the assistance of the software application downloaded from a plurality of server on the internet, or transferred from said appliances/equipments to the Dev, then from Dev passed to the handset; therefore allow the user(s) through the handset or via voice input to control, program, monitor, view, record, play back, said appliances/equipments via the Dev. The Dev also functions like the Dynamic Host Configuration Protocol (DHCP) server which along with the plurality of its connected household appliance (home application) or vehicle equipment accessories (auto application) form a closed-loop private LAN and/or WIFI and therefore less susceptible to outside snooping and interference. It will alert the user(s)/owner(s) of its registered handset(s) if any unauthorized device attempts to communicate with any of its household appliances/equipments.
The Dev can also be programmed, controlled, and then communicates wired/wirelessly with institutions, such as: a utility company to pass monthly user's utility usage information (i.e., electric/water/[heating & cooking gas] meter reading) so said company's computers can process and calculate the charges. The utility company then completes the payment automatically, or transmits said information to user's handset, so he/she using said handset is able to complete the transaction by paying online.
The Dev can also let the user speak to a visitor who rings the doorbell by alerting him/her via his/her handset (wherever he/she might be), thus allowing their communication through the intercom (front door speaker and microphone). The uninvited visitor is not aware that the owner might not be at home, at the present moment.
The Dev can also let the home owner monitor the well-being of his/her pets (dogs), by communicating with the Integrated Smart Pet Door (its door, speakers and cameras), to let them out to the backyard multiple times a day and for specified times, such as: opening its door and playing the owner voice on its speakers, and enticing/commanding them back into the house by replaying the same speaker, then closing and locking the pet door.
The Dev can also let the user store/retrieve data (audio, video, files, pictures, graphic and the likes) into/from his/her private cloud 4904 of FIG. 49/51/53/54 via any registered handset.
The Dev can also be embedded into robotic device, which can be programmed and controlled remotely by the handset via the cellular network. Cellular communication is more ubiquitous, practical, in real-time and anywhere than the internet. The robotic device can be used in situations, such as: long distance medical surgery, remote rescue mission, remote firefighting and rescue, package delivering flying drones and the like.
The Dev can also be embedded into black boxes, shipping containers, and the like which can be programmed and controlled by the handset or a computer via the cellular network or satellite network (or a hybrid network consisting of cellular, wireless, wire, terrestrial and satellite) to communicate its locations to said handset or said computer.
Since the Dev is a wireless device and particularly a cellular device, it needs to be registered and activated into a cellular network, so the network computers/servers can recognize it, and allow it into their network, in order for it to communicate with other mobile devices. Unlike cellular phone handsets, tablets, personal assistants, and the like, the Dev communicates with other handsets or wireless devices, when programmed to do so by one or more of its registered handsets. It does not communicate with everybody's cellular device, nor does it respond, when others try to communicate with it. In other words, it will ignore or will not answer uninvited calls/messages (with the exception is that during its activation/registration). The Dev receives, decodes and executes commands and data from registered handset(s), and does its tasks/functions as intended/programmed, and transmits back information and/or status to handset(s)/devices. Commands and data from the handset can be in packet(s), in binary or combination of binary and ASCII text format. Commands from the handset also preferably contain encoded handset phone number, encrypted mobile security key (MSK) and password, so the Dev can differentiate them from unwanted sources. If the phone number, (and/or) MSK and the password match with the stored ones in the Dev's memory, the Dev will execute the commands accordingly. Data can also be in video and audio text format. Information and/or status from the Dev can be in packet(s), and in binary or combination of binary, ASCII, video, streaming video and audio, or streaming audio text format. The Dev also sends messages (messages in the present invention, besides being text messages can also in the form data messaging: IM, MMS “Multimedia Message Service”, iMessages) to the handset(s), to alert the owner(s) when an event happens, or sends commands to App Server or Email Server to email owner's password to his/her email address for password recovery; as are known to those of ordinary skill in the art. The MSK is a random generated encrypted security data parameter the Dev assigns for each of its registered devices (or commands as in the case of third-party command) and is transmitted by said Dev to its registering device during the activation or registration process; in other words, each MSK is associated with one of the Dev's registered handsets (devices) or a third-party command (transmitted to a third party who will has a time-limited control and monitor over the Dev). The MSK is then encoded in the commands generated by the handset which allows the Dev to identify and recognize if it communicates with its registered device(s) or a legitimate third party. The MSK provides enhanced security protection between the Dev and its registered device(s) during their communication (via cellular, internet, SRC and satellite) and if an unmatched MSK received by said Dev during the process, said Dev requests that the user is required to register his/her new unregistered device and alerts its users via text messages, voice and emails.
The Dev's function is to monitor and control its environment, communicate with other intended wireless devices; and in such a case where it functions as a security device, it has to be installed in a position, where it is not easily removed or disabled by any un-wanted person. It preferably is in the form of an embedded electronic module consisting of a microcontroller or CPU, IC (integrated chipset), EPLD, volatile and non-volatile memory (i.e., flash, RAM, SDRAM, EEPROM, ROM, SSD, storage media, . . . ) storages (for software code, application programs, cellular account information, OS, . . . ), antenna(s), cellular phone/wireless LAN chipset, SRC (Short Range Communication) interfaces, components (NFC, WI-FI, Bluetooth, USB, wireless radio frequency (RF) technology), and general I/Os. The module can be part of the automobile controlling circuitry when applies to a vehicle, or part of the home security system, when applies to the house, and part of the electronic circuitry when applies to a robotic device or a shipping container.
The Dev can obtain, store and run software applications from other devices/servers wirelessly. In the case of a vehicle, it also contains finance account application to facilitate the toll fee transaction, when bridge toll or road toll requires. It also contains features, which allow user to locate the GPS location of other registered handset(s). It also allows user to control devices/appliances at home or on remote premises by having automatic add and remove functions, which it uses to discover/find out other controlled devices, so it can add in their functionality, or later on to remove them as commanded by user via the handset.
It also offers a general purpose control system where the main handset can register other handsets, which then together can communicate with the Dev to coordinate in monitoring and controlling what is going on within the Dev's environment, such as: a robotic/surgery/search—rescue robot, and monitoring what's going through the cameras and sensors and display the real time image on the terminal screen. Or the general purpose control system can be embedded into black boxes, cargos, shipping containers and the likes so they will be programmed by the handset or computer and their positions can then be tracked and monitored in real time by said handset or said computer.
These three applications—car, home, and robotic/surgery/search-rescue operations/shipping containers/black boxes are for cited examples and do not mean that the Dev is restricted for these applications only.
In its lifetime, it most likely has several ownership changing hands, and thus it has to be easily activated and registered by its new owner, when change of ownership takes place. It also prevents an unauthorized one from activating or registering, and also alerts its owner(s) when such event happens. This makes it very easy for owner to switch to another service provider while still being active with the current provider by having the owner (through the handset) activated the Dev into the new service provider's network. After the activation to the new service provider is successfully done, the Dev deactivates itself from the previous network or optionally retains said account data when it is in Multi Accounts mode, and also transmits commands to other registered handset(s) which will update the Dev's new phone number.
Cellular phones/devices already exist in automobiles but their functions are quite limited. The main function of the current system is to take over the call, when the driver's cellular phone rings, and thus allows him/her to answer it, and communicate hands-free with the outside caller. Some other applications allow the owner of the car to remotely lock/unlock the car or start up its engine. Part of the reason, the car manufacturers have not yet provided the complete solution, as presented herein by the present invention, is how to come up with a mechanism, so that the cellular phone system (which is already inside the vehicle cellular embedded phone module, as in the case, where it takes over the function of the driver's cellular handset) can be programmed, controlled, monitored, and thus be able to communicate with the owner's handset, and execute its functions as cited herein in the present invention. Extending the hardware (microcontroller and cellular chipset) so it can interface with other devices in the car, such as: its GPS, its engine oil/fuel level, speedometer reading, door locks, car alarm, ignition system and the like, will not do much, if a clear and straight forward mechanism by which the car owner can monitor, program, and have it activated easily with his/her chosen cellular service provider so it can communicate with his/her cellular phone, has not been implemented as presented herein by the present invention.
Furthermore, the current car Security, Control & Monitor System (SCMS), for example: allows the car owner (via smart phone) to remotely lock/unlock its doors, turn on/off its ignition/horn/lights, check its engine and electrical/electronic system (e.g., fuel, coolant fluid or oil level, battery reading, etc.) and the like or being alerted via his/her handset (smart phone, smart watch, mobile device, wearable device or the like) when certain events happen to the vehicle (e.g., break in, impact etc.), has some major drawbacks; for example:
On the consumer side, the user (potential owner of the system) has few options and depends mainly on a single exclusive security service provider (SSP) who likely is the manufacturer of the system or company affiliated with it; in other words, tied to a single security service provider. The user therefore, tends to be less receptive to the product (as added equipment into his/her vehicle) because no other company would be able to provide its connecting service. Common sense tells us that, as the exclusive service provider, the SSP tends to charge more for the service and has less incentive to offer and improve its service quality. The user has no other choice but to accept the service of the sole SSP or his/her “already paid for” equipment sits in the car being unused. Furthermore, any useful or handy command (for instance, finding out the (GPS) location of the car), requires the user to pay additional costs as an option since it is likely considered as extra feature.
On the provider side, fewer car manufacturers are adopting this technology, because as mentioned above, it requires them to form a separate company or division. Alternatively, they may associate with a third party company in order to be able to provide the service for the system. Example for this is the OnStar® Corporation which is a subsidiary of General Motors.
Therefore, for owners (whose vehicles are not equipped with SCMSs) who want to have said equipment for their cars; the only option is to depend on products offered by after-market providers (for example: AutoAlarm Pro at autoalarmpro.com or Viper Start at viper.com). The upfront expense for said product is usually more costly than the before-market solutions because more labor is involved in making modification to the vehicle interior e.g., structure, mechanical and electrical changes in order to accommodate the installation. The finished product installation might not be as aesthetic since not all vehicles are made to allow for the after-market installation. The installation might impact the manufacturer's warranty of the vehicle or render its dashboard eco-system in an unpleasant way.
The reason for all this is because of the architecture of the current SCMS. The security service provider (SSP) leases the lines from the cellular phone company so their equipment can provide the two-way communication between their SCMSs and their clients' registered smart phones (the term: handset or smart phone can also be any mobile, portable or wearable device as intended within this document). To start, first the user applies for an account with the SSP preferably online by providing his/her tax ID (i.e., social security numbers), personal and financial information to the SSP; he/she then registers his/her SCMS's unique IDs (e.g., S/N) along with the registered smart phone(s) IDs (contact phone numbers, email addresses) and then downloads the app into said smart phones. The SSP can then associate the SCMS with the user and his/her account. The service thus can begin.
Furthermore, the communication between the smart phone and the SCMS which starts at the originating device (either at the smart phone or at the SCMS) must first go through the cellular network; it is then routed to the SSP equipment which verifies the device's ID against its registered accounts. The SSP equipment (i.e., switchers/routers) then transmits the data to the destination again via the cellular network. This method adds another potential drawback to the communication system because the additional SSP equipment (another layer) requirement results in additional failure junctions and more time delay into the data delivery system.
In comparison, the present invention offers a better alternative since it allows a direct communication between the smart phone (handset) and the SCMS (Dev) without third party's switching/routing equipment involved. The user can choose or switch to any available cellular service provider of his/her choice. Furthermore, car manufacturers can treat the system as an option similar to the built-in garage opener and not having any SSP to deal with. The user can always bundle the service with his/her mobile device plan to lower cost; besides insurance companies may offer drivers better terms on their premium since the insured vehicles will have more and better security options when equipped with said device. Furthermore, the SCMS manufacturing cost can be significantly lower since most of the cellular chipsets typically already have built-in GPS which would allow them to offer car buyers two extra options (GPS capability and SCMS) with the IC (integrated Circuit) cost of one.
House monitoring security system presents less of a challenge, since it is a stationary device and can be wired and monitored by a home security company. The house monitoring system also requires a phone line (expensive and prone to being disabled because the phone line can be cut) and comes with a pretty high price tag such as monthly service fee. The monitoring can only be as good as the system and the security personnel who have the responsibility of overseeing so many stations. The system has to be installed by the home security company, and they do not provide much except calling and/or alerting the owner, when something happened or the house has been breached. The owner has no idea what happened, and neither does the alarm company until the police arrives, or the owner gets home or to the business office. Often, this can be due to a false alarm, such as: a curtain falling and causing the motion sensor to trip. There are also home installed security cameras connected online to the manufacturer's website, where an owner can create, and later logs into his/her account, and sees what the cameras see, and observes what is going on. It is a passive system, in other words, the user cannot program it in order of for him/her to be alerted when a certain condition happens.
The more advanced home Security, Control & Monitor System, where the provider's equipments and SCMS are connected to the cellular network, is also similar to the vehicle security system in having similar drawbacks. As mentioned earlier, the user, who has the system installed at his/her home/business/factory/field/farm, can only depend on one exclusive SSP who likely is also the equipment manufacturer or company affiliated with it. The additional layer of having their switching/routing equipment, in between the cellular network that handles the communication, adds more failure points and extra delay in the data delivery system.
In comparison, the present invention offers better alternative since it allows a direct communication between the smart phone (handset) and the SCMS (Dev). The user can choose or switch to any available cellular service provider of his/her choice. Furthermore, it also acts as a hub or traffic controller/router, communicating or transmitting commands, statuses and/or data between the handset(s) and various house-hold (business/factory/field/farm-related) security equipment and appliances as fast as the cellular network allows. These equipment/appliance(s) can be IoT (Internet of Things) compatible (as illustrated in FIGS. 50 and 51 showing IPv4 version, but the Dev also supports IPv6) or non-WIFI SRC (Short Range Communication) or NWSRC (non-WIFI SRC) (as illustrated in FIGS. 48 and 49), such as Bluetooth, wireless RF, . . . or a mixture of both IoT (internet of Things) and NWSRC networks. The Dev thus lets user manage all these devices from one single appliance (Dev) unified with one single app while with current technology (e.g., smart appliances such as: smart lock, smart lamps, smart refrigerator, smart washing machine, smart sensors, smart oven, smart thermostat, and the likes), the user has to have an app for each separate device (smart appliance) and also has to depend on the manufacturer's equipment/server(s) for communication which adds extra delay and more failure points. Furthermore, the plurality of apps populating on the handset's screen makes them harder to manage, thus adding extra delay and a drain on its battery, etc. Furthermore, the current existing system will let anyone with the right user ID and password access to its controlled environment and thus exposes or creates loopholes to potential hackers or thieves in commandeering the owner's vehicle or causing physical and monetary damages to said owners' dwelling or worse, by intruding/peeping into their personal environment without them being aware of such violations. The present invention (Dev) prevents this from ever happening since it can recognize the user's handset (with its corresponding MSK); otherwise it requires the user to register because of his/her using an unrecognized device, and simultaneously, alerts its registered handset(s) of said action; thus allowing the owner(s) to take the appropriate or preventive action.
As mentioned earlier for vehicle owners, home owners also benefit since they can always bundle the service with his/her mobile handset plan to lower cost and insurance companies may offer home owners better terms on the premium since the insured homes have more and better security option when equipped with said device.
The present invention allows owner 24 hour monitoring system. It goes straight to the user's handset (and his/her family members'), instead of to a third party not having the capacity to fully monitor all activity, due to the multiple terminals they need to monitor. It alerts when something happens and owner(s) can see, in real-time, what happens in his/her handset (where the Dev already transmitted the related information). Programming, controlling, and monitoring are all done through the handset, while the current paid system requires keypad located inside the house, plus a remote hand-held device just to turn the system on/off, when user is near the house within a close proximity. The present invention also extends beyond providing security of home alarm system. It allows its owner(s) means to control and monitor other household appliances/equipments, such as: heating/AC, cable/satellite TV, Garage opener, entry door lock, help-alert wearer, sprinkler control system, door bell and intercom, pet's daily needs, electric meter reading and transmitting the information to utility company. It allows its owner to store and/or retrieve, via his/her handset or any portable device, notes, pictures and the likes to and/or from his/her private storage cloud, and plurality of others.
US Patent Application US20110244846A1 and US20080057929A1 by Min: “Cell Phone with Remote Control System” mentioned a remote Automobile and Home Control System by a mobile phone, within a mobile communication network, a plurality of remote systems and a server. Min described the interconnection and integration of the plurality of systems of his invention, in terms of hardware, but never mentioned how the device in vehicle/home gets registered and activated so it can be connected to the network, how it obtained its owner's phone number and the numbers of all other handsets, and how it assigned each random generated MSK for each of its registered devices (cellular phones and/or other wired/wireless devices), so it could alert the owner and family about the unexpected events.
It is therefore apparent that an urgent need exists for improved systems and methods for programming, controlling, and monitoring wireless networks.